https://modernanalyst.com RSS feeds for Business Analyst Community & Resources | Modern Analyst 60 https://modernanalyst.com/Resources/Articles/tabid/115/ID/7009/Keep-Your-Eyes-on-the-Interfaces.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=7009 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=7009&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/7009/Keep-Your-Eyes-on-the-Interfaces.aspx Business analysts must identify external interfaces and the constraints they impose on architecture and detailed designs. Conscientious designers will ensure that all the pieces of a complex system fit together correctly across their mutual interfaces. New components that developers integrate into an existing system must also conform to established interface conventions. adrian Mon, 25 Aug 2025 00:00:00 GMT f1397696-738c-4295-afcd-943feb885714:7009 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5800/The-Art-of-Writing-Specifications-in-an-Agile-Ecosystem.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=5800 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5800&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5800/The-Art-of-Writing-Specifications-in-an-Agile-Ecosystem.aspx Writing functional specifications as a business analyst (BA) in an agile ecosystem is a challenge of a different kind. You no longer have the luxury of time (unlike bigger waterfall projects). You no longer can be sure with a specification version as the final document (because of the iterative philosophy). You are not sure how comprehensive the functional specification should be (Agile manifesto: working software over comprehensive documentation). anand.pushkar Mon, 15 Mar 2021 00:11:00 GMT f1397696-738c-4295-afcd-943feb885714:5800 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5793/Overcoming-Common-Business-Analysis-Challenges-Related-to-Glossaries.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=5793 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5793&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5793/Overcoming-Common-Business-Analysis-Challenges-Related-to-Glossaries.aspx Have you ever imagined a situation wherein your vocabulary is missing all of a sudden? What would happen if words weren’t there? Or our vocabulary shrank like ‘Honey I Shrunk the Kids’? Next to silence, words are a very important part of our conversations :-). When it comes to Business Analysis, there are many challenges around definitions. The project Glossary should contain all key business terms. It is such a straight forward thing but we may assume those things. We may put a little less emphasis on creating a rich project Glossary. Let us zoom in a bit into the common challenges of glossaries and also discuss how to overcome them. Swatipitre Sun, 07 Mar 2021 05:01:00 GMT f1397696-738c-4295-afcd-943feb885714:5793 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5347/Requirements-In-Context-Part-3-Scope-High-Level-Requirements.aspx#Comments 3 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=5347 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5347&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5347/Requirements-In-Context-Part-3-Scope-High-Level-Requirements.aspx Project Scope. We will see how scope statements, when making reference to business functionality, lead directly to High-Level requirements.  Gathering requirements for a business information system is most often done within the context of a project. Approval of a project includes its sponsors signing off on its scope. The scope for a business information system project is typically defined in functional terms. Items in scope make reference to (or should make reference to) business functions, processes and/or activities that are to be delivered. adrian Sun, 05 May 2019 20:46:00 GMT f1397696-738c-4295-afcd-943feb885714:5347 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5144/Managing-Requirements-is-an-Art-Mastered-by-a-Business-Analyst.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=5144 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5144&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5144/Managing-Requirements-is-an-Art-Mastered-by-a-Business-Analyst.aspx In a classic business analyst universe, requirements are the soul of all the work a business analyst does. If a business analyst fails to identify and translate the right requirements, they’re out of a job. This is the reason why a successful business analyst is always good at requirements handling/management process. What makes requirements an essential part of a BA’s job? For a business analyst, requirements are defined as the logical and essential steps which needs to be fulfilled in order to achieve a successful end-state or a solution to a stakeholder’s business problem. These requirements drive the solution and are the key elements of any successful solution implementation. Business analysts are the ones who not only ensures the expected solution is delivered, but they’re also the owner of the requirements handling/management process. Business analysts identify the right requirements and help them convert into a form consumable by delivery teams to deliver the expected outcome in a timely manner. The requirements management/handling process consists of 4 basic steps: Discovery, Analyze, Draft and Implement. 1.     Discovery Requirements discovery is a phase in which we identify, gather and scope the requirements. This phase builds the basic requirements framework for delivery. To identify and gather requirements, a business analyst uses various requirements elicitation techniques like observation, shadowing, protocol analysis, apprenticeship, prototyping, focus groups, scenario’s, background research and many others. These techniques are aimed towards gathering information related to a business problem and/or a solution that business stakeholders are trying to achieve. Requirements identification is a highly interactive activity, which relies on the involvement of the right stakeholders. Elicitation activities continue while a business analyst traverse through other stages/steps of requirements gathering. It is very important for a business analyst to not only identify but to scope the requirement. Requirements are driven by information collected by various elicitation methods; however, the relevancy of the requirement needs to be determined. The simplest way to do so is to perform some of the elicitation techniques repetitively. Look for facts via secondary support of documents or information from another source just to verify. Chart your scope based on the overall direction of the information flow and the end-state which stakeholders are trying to achieve. Scoping cannot be definitive in the business analyst’s landscape. It’s a loose boundary which needs to be flexible enough to account for other business or priority changes. Loose boundaries do help the business analyst in defining a playground where they need to operate for a successful outcome. 2.     Analyze The most important activity of the requirements handling process is to analyze a requirement. Analyzing a requirement will provide us with a definite outcome along with the complete information on achieving that outcome. There can be various types of analysis like strategic analysis, functional and technical analysis. Strategic analysis is performed by understanding the strengths, weakness, opportunities and threats provided by implementing this requirement. It helps a business analyst to understand the priority and criticality of the requirement which also determines how essential it is for a business to implement those requirements. Functional analysis provides an ability to understand the requirement from the end user perspective.  It is performed by interacting with people who’re impacted by the implementation of requirements. This provides unique opportunity for a business analyst to shape the solution in a way that accommodates the minimal, easy to adapt change to the end users or the impacted. Technical analysis is performed by further breaking down functional requirements into a series of small implementation steps which a delivery person can understand. It is the delivery person/team who needs to deliver the technical solution. It is important to not miss any aspect of functional requirement to be translated into technical requirements which is a supporting pillar for successful solution implementation. Depending upon the type of analysis, we determine the type of requirement. Upon successfully analyzing and understanding the type of requirement we start drafting requirements into various artifacts. 3.     Draft Once a business analyst has understood the type of requirements and its expected outcome, business analyst can draft those requirements in their respective artifacts. There’re various artifacts such as business requirements document and/or specification requirements document and user stories which are authored and owned by a business analyst while there’re some other like project charter, technical design document or anything alike to which a business analyst contributes actively. Drafting of requirements take the utmost time as the translation needs clarifications and numerous back and forth interactions. Once a requirement drafting is complete, it’s time to walk them through with the entire team. 4.     Implement The first step of requirements implementation is to arrange for a walk-through of freshly drafted requirements where the audience includes all stakeholders including delivery team. This walk-through session helps with course correction of requirements if there’s a miss while drafting them. Also, requirements walkthrough is a common platform where in the stakeholders and other team members have the opportunity to ensure alignment of the requirements to the desired end state. Once the requirements are defined and finalized, business analysts have to ensure continuous requirement refinement for successful delivery. This is the final step of requirements management process. Once the requirement has been identified, scoped, analyzed, drafted and confirmed, business analysts have to keep their eye out for on-going business changes, these changes may affect any of the existing requirements and their desired outcomes. As business changes are constant, the impacts on the already drafted requirements is constant. There is a small deviation of requirements which can still be managed by refining the requirement and updating them, but then if the deviation requires additional effort for which the cost involved is high, then changes are to be considered for enhancement. This decision must be evaluated by a business analyst before taking appropriate actions accordingly. At this stage, all the requirements are the guiding principle for the delivery team to deliver the solution. Requirements Handling/Management Process is the one, a business analyst has to master to be considered as successful. Author: Nimil Parikh, Business Analyst Nimil Parikh is a new generation business analyst who transforms business processes by leveraging IT tools and applications. He has over 7 years of experience modeling, analyzing, measuring, improving, optimizing and automating business processes. He adds value by his ability to context switch while providing cross-functional business solution and ensuring timely delivery by managing and streamlining business processes and driving strategic leadership. He is known to introduce IT business transformation and ensure successful implementation. Nimil possess MBA from San Jose State university, MBA Marketing and Information technology engineering from India. Nimil lives in Campbell, California. He enjoys challenges and believes in making things right. Reach him via email – parikhnimil@yahoo.co.in   Nimil Parikh Sun, 21 Oct 2018 21:22:00 GMT f1397696-738c-4295-afcd-943feb885714:5144 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5083/Lets-explore-Business-Analysts-Toolbox.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=5083 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=5083&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/5083/Lets-explore-Business-Analysts-Toolbox.aspx Chaos! Stress! Everyday mess! Isn’t this an everyday situation for a business analyst? If not, either you’ve job satisfaction or you’re not being introduced to the real world of business analysis. A person might possess great skills, however, (s)he might not be able to utilize skills without the right mix of tools and environment. A toolbox enables a person to implement the skills in the most efficient way. Possessing necessary tools is just the one part of it. Another is the knowledge to utilize the right tools at the right time to cater the solution and ensure timely committed delivery. What are these tools? How do we map the usage of tools to the given circumstance? How can we efficiently utilize the tool? Does it depend on the solution or the approach? Nimil Parikh Sun, 08 Jul 2018 12:00:00 GMT f1397696-738c-4295-afcd-943feb885714:5083 https://modernanalyst.com/Resources/Articles/tabid/115/ID/4952/Business-Analysis-as-a-career-choice-Tips-to-make-you-succeed.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=4952 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=4952&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/4952/Business-Analysis-as-a-career-choice-Tips-to-make-you-succeed.aspx How do you become a business analyst and where do you begin?  So you want to cross over to the land of analysis? A land of ‘schizophrenic’ people who need to possess multiple skills and make meaning out of ambiguity. You'll need to break down complex problems into bite-size chunks that can be easily understood. You'll also need to manage different stakeholders and break down knowledge barriers formed by these stakeholders. (Most having been in their organisations for decades) Finally, you'll need to develop a thick skin to stand in the firing line.   Transform VA Sun, 04 Mar 2018 21:10:00 GMT f1397696-738c-4295-afcd-943feb885714:4952 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3871/BDD-An-introduction-to-feature-files.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=3871 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=3871&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3871/BDD-An-introduction-to-feature-files.aspx The purpose of this article is to explore feature files. Feature files are documents that contain those Gherkin scenarios & requirements – they can be very useful to teams working on BDD projects. Feature files may be a key deliverable for BAs.  Feature files are where BAs store requirements & can create the bridge between requirements and automated tests (more on that later). Transform VA Sun, 26 Nov 2017 12:48:00 GMT f1397696-738c-4295-afcd-943feb885714:3871 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3808/Getting-the-Job-Without-Previous-Domain-Experience.aspx#Comments 1 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=3808 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=3808&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3808/Getting-the-Job-Without-Previous-Domain-Experience.aspx Trying to secure a business analyst job interview in an area in which you don’t have prior experience can be a huge challenge. It’s common for recruiters and hiring managers to screen out applicants--no matter how accomplished they seem to be from their resumes--simply because the candidate’s job history doesn’t include work in the target industry...  But how do you get your foot in the door when so many recruiters and hiring managers tend to ignore applications from a candidate whose background doesn’t match the role they are trying to fill? The following tips may help. adrian Mon, 24 Jul 2017 02:01:00 GMT f1397696-738c-4295-afcd-943feb885714:3808 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3726/Differences-Duties-and-Responsibilities-of-Business-Analysts-and-System-Analysts.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=3726 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=3726&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3726/Differences-Duties-and-Responsibilities-of-Business-Analysts-and-System-Analysts.aspx A business analyst is a person who analyzes, organizes, explores, scrutinizes and investigates an organization and documents its business and also assesses the business model and integrates the whole organization with modern technology. The Business Analyst role is mostly about documenting, verifying, recording and gathering the business requirements and its role is mostly associated with the information technology industry. Bhairav24 Sun, 19 Mar 2017 21:50:00 GMT f1397696-738c-4295-afcd-943feb885714:3726 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3692/How-to-tell-stories-as-a-Business-Analyst.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=3692 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=3692&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3692/How-to-tell-stories-as-a-Business-Analyst.aspx A story is defined as a narrative or tale, true or imaginary. Each story has a moral hidden in it. A story writer won't directly say that hard work and patience is the key to success. Instead the writer came up with a story of Hare and Tortoise. And if we observe carefully, stories are everywhere; we ask a friend about her love story, we watch a prime time news story, we ask a new friend about his life's story, the movie I watched the other day had a good story.  Wed, 28 Dec 2016 10:33:00 GMT f1397696-738c-4295-afcd-943feb885714:3692 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3287/How-not-to-get-lost-in-data-jungle.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=3287 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=3287&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3287/How-not-to-get-lost-in-data-jungle.aspx Data migration is typically the most forgotten or underestimated component of an IT project which is the process of making a copy of data and moving it from one system to another, preferably without disrupting or disabling active business processes. On some occasions, it is not easy to understand that a data migration is needed in the project and most of the times data migration is not seen as an item that its requirements needs to be captured during analysis phase. That’s why migration related problems begin during development or testing phase when data need is identified or when the data from the old system refuses to fit properly into your new user interfaces or business rules despite the transportation of the old data. For a successful project, the need of a data migration and its requirements must to be identified early beginning of analysis phase and further actions should be reflected to project plan accordingly. But how? Data migration strategies are a whole different detailed topic and they will not be mentioned here but capturing the essentials of data nature is a life-saver activity which is the targeted idea of this work. 1. Will you need a data migration? Identify it during elicitation phase if possible. If not, analysis phase is also ok but be careful and just identify the need as earlier as possible. Ask data related simple questions. Do your requirements mention from the systems need to be shut down? If yes, does this system keeps any data? Is your project a replacement project for an old system? If yes, does this system keeps any data? Do your requirements mention from entities that are already used in your company’s systems? In order to use that data do your new system’s data model needs to keep them as well. Watch out, it may mean also a nasty synchronization! If one of answers is yes, you will need a potential data migration. Just continue to get more details. 2. How to capture requirements and define business rules? If you determine that you need a data migration, be careful and specify at least following details in your analysis.   2.1 Identify if your company have multiple data sources for that entities. If yes, determine the master and the fate of other systems’ data. You will see how many systems you are dealing with. It is important to know how and where data is stored, backed up, and if it is archived. 2.2 Data profiling: Data profiling is a “must have” activity to understand what are specs of the material you will be working on. Conduct profiling activities and classify the data, such as data with missing unique ID’s or missing first name and last name or false data such as numeric values as first name and other useful information like length, type, candidate for primary key, etc. Results of the profiling will guide you to design user interfaces and capture business rules. 2.3 Do you need data cleansing? According the data profiling, you will see if you need cleansing activities and what will be the final structure of the data you will be working on. Also you will be able to clarify cleansing related activities on the project timeline which will provide a cleaner vision for the project timeline. If your answer is no, definitely check the section 2.6. 2.4 Data structures must be well understood if your project requires design of user interfaces or data forms. Consider data structures while determining dynamic user interfaces or form context. For example, old system may store the phone number and its extension in one field by separating data by “–“. This means two numbers are stored in one field and you should consider such constraints while you are designing a new interface with multiple fields on section 2.8 or determine ways to separate phone number and its extension effectively while moving the data as mentioned on section 2.7. 2.5 Fate of the historical data:  Take into account if historical data will be migrated or not. It may affect your user interfaces or business processes. 2.6 Fate of the missing or dirty data: After profiling, most probably you will see that some of your data is not clean or adequate to use in further actions. For example, you are working on sensible customer data and national identity number is mandatory but some records do not have identity numbers. It will cause you problems to pinpoint the customer or you will face further problems if this information is mandatory to display customer on the screen.  Even worse, if you have validations based on the identity number such as debt control or billing, the system will not be able to conduct such validations. Always check whether data ownership belongs to a specific business unit. If yes, let them decide to the fate of data. Decide whether the data is just enough to use or will it cause problems to conduct business processes. Will you migrate such data? If yes, sections 2.8 and 2.10 will be highly important for you. Is it possible to clean or enhance problematic data somehow? If yes, how? Determine the way and related requirements. If you decide not to move such data, always consult with your business unit for possible further actions. They may need to find the customer and inform him/her legally according his/her account status or they may need another manual/automation processes.  2.7 Data mapping is basically the activity of creating a map of the existing data model by matching each entity&field with the future data model. Each entity should be mapped correctly and in details to be able to move data successfully. The map is an essential item of data migration strategy which is a whole another topic and not be mentioned here in details. Based on the mapping, you can see the gap between your legacies and your future and you can use the information on section 2.8 2.8 Screen validations and rules: Results of sections 2.2-2.7 will give you clear information about user interface validations and potential need of new business processes. 2.8.1 Screen validations? Define entity specs such as type and length based on the profiling results, the information will guide you to design potential data forms. Define the rules for the gap. If entities are not matching neatly, define UI standards and validation rules accordingly. Such as, will be these entities optional or if two different data are kept in one field, will you continue to collect and display them together? 2.8.2 New processes is needed? If you decided to transport problematic data; You may need to create new processes to correct such data. For example if the identity number is mandatory and your customer update process originally does not allow to update the number, in order to enable the correction of the customer information, you may need the define rules such as displaying identity number field editable. You may create new processes to alert the system or trigger different actions. 2.9 Define security & security measures such as encryption. If data needs to be migrated encrypted, general rules shall be set during analysis phase. 2.10 Define migration acceptance criteria such as data quality, migration duration etc. if it will cause termination on your services 2.11 Define the fate of the legacy data: Will you continue to keep the data on the legacy systems? If yes, determine whether a synchronization is needed with the new system or not? How long the data should be kept on legacy system? What are maintenance rules?   3.    What is next? Of course, plan the future! All answers will guide you for further activities which need to be added to the project plan in details. Identifying these steps at the beginning will prevent you from future unexpected surprises and definitely will help to close the project on time. 3.1 Rehearsals A clean migration needs rehearsals where you can have a look at your situation. 3.2 Testing scenarios Requirements need to be tested and since migration activity creates its own requirements, testing scenarios should cover these requirements as well. Author: Aylin Şen, Senior Business Analyst aylinsen Thu, 28 May 2015 16:49:00 GMT f1397696-738c-4295-afcd-943feb885714:3287 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2495/The-3-Amigos--BA-QA-and-Developer.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=2495 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=2495&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/2495/The-3-Amigos--BA-QA-and-Developer.aspx The 3 Amigos (sometimes referred to as a “Specification Workshop”) is a meeting where the Business Analyst presents requirements and test scenarios (collectively called a “feature”) for review by a member of the development team and a member of the quality assurance team. ryanhewitt Wed, 17 Dec 2014 19:29:00 GMT f1397696-738c-4295-afcd-943feb885714:2495 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1892/Business-Analysis-and-User-Experience.aspx#Comments 1 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=1892 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=1892&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1892/Business-Analysis-and-User-Experience.aspx At UC Berkeley there has been an increasing awareness of the importance of business analysis (BA) and user experience (UX) in the software development lifecycle. In this article we will discuss the advantages of involving BA and UX practitioners in your development process, when and how to involve them, and the similarities and differences between the two professions. speeditonline Mon, 04 Jul 2011 10:08:00 GMT f1397696-738c-4295-afcd-943feb885714:1892 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1713/The-Structure-of-Business-Analysis-Documents.aspx#Comments 7 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=1713 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=1713&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1713/The-Structure-of-Business-Analysis-Documents.aspx The structure of business analysis documents isn't a commonly discussed topic. This article will show what documents are produced by a Business Analyst and the main sections they contain. These are the main documents produced by a BA over the course of a project...   AlexK Mon, 28 Feb 2011 05:09:00 GMT f1397696-738c-4295-afcd-943feb885714:1713 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1714/A-Data-Driven-Approach-to-Specifications.aspx#Comments 3 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=1714 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=1714&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1714/A-Data-Driven-Approach-to-Specifications.aspx Business requirements are usually captured in narratives and graphics that, regardless of how detailed, structured, cross-referenced and validated, are fundamentally imprecise. A data-driven approach to specifications has the potential to help avoid these problems and subsequently decrease the risk and increase the return on companies' IT investments. speeditonline Mon, 14 Feb 2011 05:36:00 GMT f1397696-738c-4295-afcd-943feb885714:1714 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1625/Just-Enough-Documentation.aspx#Comments 1 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=1625 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=1625&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1625/Just-Enough-Documentation.aspx Is documentation a blessing or a curse? If you’re working on an agile project does it get in the way? If you’re updating a core system that runs your company’s business, are you cursing the analyst who didn’t adequately document all the business functionality? Is today’s agile project tomorrow’s core system? pddean Mon, 29 Nov 2010 05:01:00 GMT f1397696-738c-4295-afcd-943feb885714:1625 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1568/Report-Requirements-An-Overview.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=1568 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=1568&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/1568/Report-Requirements-An-Overview.aspx A user of almost any given software system or business application will require precise analytics in order to objectively measure its effectiveness, or the effectiveness of an associated product. These analytics –or reports—therefore, must measure the right criteria at the right time(s) in the right way in order to be useful to the user. For that reason, any newly proposed reporting function requires careful, measured, thoughtful and thoroughly vetted requirements in order to ensure its efficacy. speeditonline Thu, 21 Oct 2010 09:25:00 GMT f1397696-738c-4295-afcd-943feb885714:1568 https://modernanalyst.com/Resources/Articles/tabid/115/ID/923/Requirements-Specifications-on-Agile-Projects.aspx#Comments 3 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=923 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=923&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/923/Requirements-Specifications-on-Agile-Projects.aspx Business analysis is an important aspect of agile software development projects, but the agile approach is significantly different than the traditional, serial approach of yesteryear. Because the agile approach to business analysis is different the approach to requirements specification is also different, for many traditionalists this will prove to be a significant cultural shock to them at first. In this article I briefly overview how business analysis activities fit into an agile approach, question some of the dogma around documentation within the traditional community, summarize some of the evidence showing that agile approaches are more effective in practice than traditional approaches, and end with strategies for specifying requirements on an agile project. adrian Wed, 06 May 2009 04:28:00 GMT f1397696-738c-4295-afcd-943feb885714:923 https://modernanalyst.com/Resources/Articles/tabid/115/ID/292/Best-Practices-for-AgileLean-Documentation.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=292 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=292&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/292/Best-Practices-for-AgileLean-Documentation.aspx Ideally, an agile document is just barely good enough, or just barely sufficient, for the situation at hand. Documentation is an important part of agile software development projects, but unlike traditionalists who often see documentation as a risk reduction strategy, agilists typically see documentation as a strategy which increases overall project risk and therefore strive to be as efficient as possible when it comes to documentation. Agilists write documentation when that's the best way to achieve the relevant goals, but there often proves to be better ways to achieve those goals than writing static documentation. This article summarizes common "best practices" which agilists have adopted with respect to documentation. adrian Tue, 04 Mar 2008 21:16:00 GMT f1397696-738c-4295-afcd-943feb885714:292 https://modernanalyst.com/Resources/Articles/tabid/115/ID/247/Understanding-the-Specifications-Puzzle.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=247 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=247&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/247/Understanding-the-Specifications-Puzzle.aspx THE ANALYST (aka, Systems Analyst, Systems Engineer, Systems Architect, Business Analyst) - requires specifications about the end-User's information requirements in order to design a system solution.  This is normally based on a definition of the user's business actions and/or decisions to be supported.  Following the system design, the Analyst produces the specifications required by the Programmer and DBA to fulfill their part of the puzzle.  From this perspective, the Analyst is the translator between the end-User and the Programmers and DBAs. Each party has his own unique perspective of the puzzle and, as such, requires different "specifications."  To compound the problem though, the role of the Analyst sharply diminished over the years, leaving it to the Programmers to try and determine what the end-User needs, a skill they are typically not trained or suited for.  timbryce Fri, 08 Feb 2008 15:23:00 GMT f1397696-738c-4295-afcd-943feb885714:247 https://modernanalyst.com/Resources/Articles/tabid/115/ID/198/Functional-Specification--a-Tutorial.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=198 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=198&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/198/Functional-Specification--a-Tutorial.aspx What Is A Functional Specification? Functional specifications (functional specs), in the end, are the blueprint for how you want a particular web project or application to look and work. It details what the finished product will do, how a user will interact with it, and what it will look like. By creating a blueprint of the product first, time and productivity are saved during the development stage because the programmers can program instead of also working out the logic of the user-experience. It will also enable you to manage the expectations of your clients or management, as they will know exactly what to expect. Why write a Functional Spec? A key benefit of writing up a Functional Spec is in streamlining the development process. The developer working from the spec has, ideally, all of their questions answered about the application and can start building it. And since this is a spec that was approved by the client, they are building nothing less than what the client is expecting. There should be nothing left to guess or interpret when the spec is completed...and this, in a nut, explains my love affair with the Functional Spec. Who writes a Functional Spec? The functional spec should be written by someone who is not involved in any other aspect of the project. You will want somebody who is very familiar with user-interface issues and web design, familiar enough with technology to know its limitations and capabilities, and someone who is a very skilled and detailed writer. While writing a spec, you will spend much of your time imagining how a user might use a certain feature and how they may navigate their way through the information. Not only do you need to map this world out visually, but you also have to write out in great detail what this world does; all the while, balancing everything within the current technological limitations and business demands. The functional spec writer's sole concern is marrying the user-experience with the various departmental, business, and technical requirements of the project.  Author: Allen W. Smith adrian Sun, 02 Dec 2007 06:18:00 GMT f1397696-738c-4295-afcd-943feb885714:198 https://modernanalyst.com/Resources/Articles/tabid/115/ID/103/Breathing-life-into-living-documents.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=103 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=103&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/103/Breathing-life-into-living-documents.aspx A multitude of sins can be hidden behind the phrase “living document.” You can submit documents that are incomplete or inconsistent as long as you promise to fix it later. In this month’s issue of Strategic Software Engineering, I want to talk about the strategic importance of being realistic about the state of knowledge, plans and documents in a project. When I first heard the term “living document” some years ago, I liked the concept. It signified an awareness that in an iterative, incremental development process we should be open to revisiting and revising designs, plans, and schedules. Markets become crowded, technologies emerge, and we learn. Updating strategies to reflect these new circumstances is a reasonable thing to do. More recently I have encountered much abuse of the concept. “Don’t worry, it’s a living document. We can fix it later.” This indicates a misunderstanding of, or disregard for, the real intent of a living document. Releasing a document that is incomplete, inconsistent, or even incorrect is risky. Any document that is released will set expectations to a degree. Future releases will not have the same impact as the original and even if the document lives on the web where changes can be made centrally, some paper copies will undoubtedly confound the change process. Author: John D. McGregor adrian Thu, 20 Sep 2007 18:35:00 GMT f1397696-738c-4295-afcd-943feb885714:103 https://modernanalyst.com/Resources/Articles/tabid/115/ID/77/Introduction-to-Requirements-The-Critical-Details-That-Make-or-Break-a-Project.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=77 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=77&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/77/Introduction-to-Requirements-The-Critical-Details-That-Make-or-Break-a-Project.aspx Every project has requirements. It doesn't matter if it's building hardware solutions, developing software solutions, installing networks, protecting data, or training users. For the project to be a success, knowing what the requirements are is an absolute must. Requirements exist for virtually any components of a project or task. For example, a project may require specific methods, expertise levels of personnel, or the format of deliverables. This whitepaper will discuss the various kinds of information technology requirements, their importance, the different requirement types, the concept of requirements engineering, and the process for gathering requirements. Author: Global Knowledge lilesj Thu, 13 Sep 2007 10:33:00 GMT f1397696-738c-4295-afcd-943feb885714:77 https://modernanalyst.com/Resources/Articles/tabid/115/ID/70/Requirements-When-the-Field-Isnt-Green.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=70 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=70&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/70/Requirements-When-the-Field-Isnt-Green.aspx  Most books and articles on software requirements are written as though you’re gathering requirements for a brand-new product—what’s sometimes called a green-field project. In reality, few people have that opportunity on every project. Many developers work on maintenance projects. In such a project you’re usually adding new features to existing systems, modifying functionality to comply with updated business rules, or building extensions onto commercial packages. Too often, you can’t find anything resembling a requirements specification for the system you’re enhancing. It’s not unusual to have to maintain a system without adequate documentation, with the original developers who held all the critical information in their heads being long gone. If you’re in such a situation, you might be tempted to reject the requirements literature as irrelevant. Not so! You can apply several useful requirements engineering methods even in these situations—even when you’re squeezing new functionality into an unruly product in a documentation vacuum. The same ideas apply to iterative development projects doing a series of successive releases. Here I’ll describe seven principles to help you deal with requirements issues in such maintenance situations. We’ll also look at ways in which thoughtfully applied requirements development and management practices can help you improve both your product quality and your ability to perform future maintenance. Author: Karl Wiegers adrian Thu, 06 Sep 2007 16:28:00 GMT f1397696-738c-4295-afcd-943feb885714:70 https://modernanalyst.com/Resources/Articles/tabid/115/ID/127/How-to-Document-Use-Cases.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=127 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=127&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/127/How-to-Document-Use-Cases.aspx A use case represents a case of use of a system, ideally one that captures a functional requirement in terms of an identifiable and testable goal. So, what is the best way to document a use case? Approaches to content range from diagrammatic to textual, formal to free form, expansive and detailed to brief and abstract. The approaches to tool usage and authoring are just as varied. Here are some suggestions for a simple and streamlined, yet reasoned and thorough, approach to use case documentation. Author: Kevlin Henney adrian Sun, 29 Jul 2007 21:36:00 GMT f1397696-738c-4295-afcd-943feb885714:127 https://modernanalyst.com/Resources/Articles/tabid/115/ID/49/Painless-Functional-Specifications--Part-4-Tips.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=49 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=49&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/49/Painless-Functional-Specifications--Part-4-Tips.aspx In this fourth and final part of the series I'll share some of my advice for writing good specs. The biggest complaint you'll hear from teams that do write specs is that "nobody reads them." When nobody reads specs, the people who write them tend to get a little bit cynical. It's like the old Dilbert cartoon in which engineers use stacks of 4-inch thick specs to build extensions to their cubicles. At your typical big, bureaucratic company, everybody spends months and months writing boring specs. Once the spec is done, it goes up on the shelf, never to be taken down again, and the product is implemented from scratch without any regard to what the spec said, because nobody read the spec, because it was so dang mind-numbing. The very process of writing the spec might have been a good exercise, because it forced everyone, at least, to think over the issues. But the fact that the spec was shelved (unread and unloved) when it was completed makes people feel like it was all a bunch of work for naught. Also, if your spec never gets read, you get a lot of arguments when the finished product is delivered. Somebody (management, marketing, or a customer) says: "wait a minute! You promised me that there would be a Clam Steamer! Where's the clam steamer?" And the programmers say, "no, actually, if you look on the spec on chapter 3, subchapter 4, paragraph 2.3.0.1, you'll see it says quite explicitly 'no clam steamer.'" But that doesn't satisfy the customer, who is always right, so the grumpy programmers have to go retrofit a clam steamer into the thing (making them even more cynical about specs). Or a manager says, "hey, all the wording on this dialog is too verbose, and there should be an advertisement at the top of every dialog box." And the programmers say, in frustration, "but you approved the spec which precisely listed the layout and contents of every dialog box!" But of course, the manager hadn't actually read the spec, because when he tried, his brain started seeping out through his eye sockets, and anyway, it was interfering with his Tuesday golf game. So. Specs are good, but not if nobody reads them. As a spec-writer, you have to trick people into reading your stuff, and you should also probably make an effort not to cause any already-too-small brains to leak out through eye-sockets. Tricking people into reading your stuff is usually just a matter of good writing. But it's not fair of me to just say "be a good writer" and leave it at that. Here are four easy rules that you absolutely must follow to make specs that get read. Author: Joel Spolsky admin Sat, 14 Apr 2007 10:31:00 GMT f1397696-738c-4295-afcd-943feb885714:49 https://modernanalyst.com/Resources/Articles/tabid/115/ID/48/Painless-Functional-Specifications--Part-3-But-How.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=48 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=48&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/48/Painless-Functional-Specifications--Part-3-But-How.aspx Now that you've read all about why you need a spec and what a spec has in it, let's talk about who should write them. Who writes specs? Let me give you a little Microsoft history here. When Microsoft started growing seriously in the 1980s, everybody there had read The Mythical Man-Month, one of the classics of software management. (If you haven't read it, I highly recommend it.) The main point of that book was that when you add more programmers to a late project, it gets even later. That's because when you have n programmers on a team, the number of communication paths is n(n-1)/2, which grows at O(n2). So the programmers at Microsoft were worried about how to write bigger and bigger programs, when the prevailing wisdom of the day was that adding programmers just makes things worse. Charles Simonyi, Microsoft's long time "chief architect", suggested the concept of master programmers. The idea was basically that one master programmer would be responsible for writing all the code, but he or she would rely on a team of junior programmers as "code slaves". Instead of worrying about debugging every function, the master programmer would basically just prototype each function, creating the bare outline, and then throw it to one of the junior programmers to implement.  (Of course, Simonyi would be the Master Master Programmer.) The term "Master Programmer" was a bit too medieval, so Microsoft went with "Program Manager." Theoretically, this was supposed to solve the Mythical Man-Month problem, because nobody has to talk to anyone else -- every junior programmer only talks to the one program manager, and so communication grows at O(n) instead of O(n2). Well, Simonyi may know Hungarian Notation, but he doesn't know Peopleware. Nobody wants to be a code slave. The system didn't work at all. Eventually, Microsoft discovered that despite the alleged Mythical Man Month, you can still add smart people to a team and get increased output, although at decreasing marginal values. The Excel team had 50 programmers when I was there, and it was marginally more productive than a team of 25 would have been -- but not twice as productive. The idea of master/slave programming was discredited, but Microsoft still had these people called program managers bouncing around. A smart man named Jabe Blumenthal basically reinvented the position of program manager. Henceforth, the program manager would own the design and the spec for products. Since then, program managers at Microsoft gather requirements, figure out what the code is supposed to do, and write the specs. Author: Joel Spolsky admin Sat, 14 Apr 2007 10:26:00 GMT f1397696-738c-4295-afcd-943feb885714:48 https://modernanalyst.com/Resources/Articles/tabid/115/ID/47/Painless-Functional-Specifications--Part-2-Whats-a-Spec.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=47 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=47&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/47/Painless-Functional-Specifications--Part-2-Whats-a-Spec.aspx This series of articles is about functional specifications, not technical specifications. People get these mixed up. I don't know if there's any standard terminology, but here's what I mean when I use these terms. A functional specification describes how a product will work entirely from the user's perspective. It doesn't care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on. A technical specification describes the internal implementation of the program. It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc. When you design a product, inside and out, the most important thing is to nail down the user experience. What are the screens, how do they work, what do they do. Later, you worry about how to get from here to there. There's no use arguing about what programming language to use before you've decided what your product is going to do. In this series, I'm only talking about functional specifications. Author: Joel Spolsky admin Sat, 14 Apr 2007 10:24:00 GMT f1397696-738c-4295-afcd-943feb885714:47 https://modernanalyst.com/Resources/Articles/tabid/115/ID/46/Painless-Functional-Specifications--Part-1-Why-Bother.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=46 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=46&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/46/Painless-Functional-Specifications--Part-1-Why-Bother.aspx It seems that specs are like flossing: everybody knows they should be writing them, but nobody does. Why won't people write specs? People claim that it's because they're saving time by skipping the spec-writing phase. They act as if spec-writing was a luxury reserved for NASA space shuttle engineers, or people who work for giant, established insurance companies. Balderdash. First of all, failing to write a spec is the single biggest unnecessary risk you take in a software project. It's as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to "wing it." Programmers and software engineers who dive into code without writing a spec tend to think they're cool gunslingers, shooting from the hip. They're not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for. I believe that on any non-trivial project (more than about 1 week of coding or more than 1 programmer), if you don't have a spec, you will always spend more time and create lower quality code. Here's why. Author: Joel Spolsky admin Sat, 14 Apr 2007 10:21:00 GMT f1397696-738c-4295-afcd-943feb885714:46 https://modernanalyst.com/Resources/Articles/tabid/115/ID/106/Form-over-Substance.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=106 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=106&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/106/Form-over-Substance.aspx Beware of the colleague or supplier who spends large amounts of time in meetings discussing the format, sequence, and wording of documents they will deliver and very little time on the actual content. Strategically, substance is what counts. In this issue of Strategic Software Engineering I will point to some common problems when form becomes a higher priority than substance and what value is added when these problems are addressed. Author: John D. McGregor adrian Tue, 20 Mar 2007 19:03:00 GMT f1397696-738c-4295-afcd-943feb885714:106